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Bruce J. MacLennan 
Computer Science Department 
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Monterey, CA 93943 



Abstract: 

This is the fifth report of a series exploring the use of the H programming notation to prototype a pro- 
gramming environment. This environment includes an interpreter, unparser, syntax directed editor, 
command interpreter, debugger and code generator, and supports programming in a small applicative 
language. The present report presents a code generator operating on abstract syntax trees. The code 
generation process is implemented as an evaluator over a nonstandard domain. An implementation of 
the code generator is listed in the appendices. 



1. Introduction 

Our goal in this series of reports* j MacLennan85b, MacLennan85c, MacLenn an86a. MacLennan86b| is 
to explore in the context of a very simple language the use of the H programming notation MacLen- 
nan83, MacLennan85a to implement some of the tools that constitute a programming environment. 

In this report we define a code generator for abstract programs. The code generator will be a 
member of the same family as the interpreter and the unparser. That is, it will be an evaluator for 
abstract programs defined on the domain of code sequences. First we discuss machine and run-time 
structure; next, informal translations; and finally present the translation rules. 

2. Target Machine Structure 

We will generate code for a stack machine with several special purpose registers (EP. SP) and several 

temporary registers (Tl. T2). It has the following instructions; 

Support for this research was provided by the Office of Naval Research under contract N00014-86- WR-24092. 
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LDC k — load constant 



• ADD, SUB, MUL, DIV, EQL, etc. — arithmetic 

• JMP /, JMPT / — unconditional jump, jump on true 

• LBL / — define label 

• SKIP 6 — skip down static chain 

• LOD — load contents of variable 

• ENTER, EXIT — block control 

• CALL, RETURN — function control 

• PUSH r, POP r — stack control 

• BREAK — enter debugger 

3. Run-Time Structure 

We use a conventional static-chain implementation for statically-scoped languages. Note that this 
stack-based activation record structure will not support function- valued functions, which are supported 
by the interpreter. This incompatibility between the interpreter and code generator is very serious, but 
not addressed in the present report, since it would not affect the use of H as a tool for writing the code 
generator. Exercise for the reader: define a non-stack-based activation record structure that solves this 
problem. 

Consider the following program: 

let A = 1 

fune F X = 

let B = (X x A) 
let C = 3 



(if (X > 0) 
then F (C + (X - B) ) 
else 0 ) 
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F (A x 2) ] 



This diagram illustrates the run-time data structures when execution is within the ‘let B = block on 



the recursive invocation of F: 



^jDyn l\ vn ) c 

C kj (TV 1 



Notice how the static links for both 




e p /ip pair is the dynamic link. 
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4. Informal Translation Rules 



4.1 Constants, Variables and Applications 

For constants we merely stack the constant value: 

k LDC k 

For variables we must first scan down the static chain to the environment of definition of the variable. 
Then the value of the local variable from that environment’s activation record can be loaded onto the 
stack: 

SKIP 6 
v ^ LOD 

where S is the static distance to v's activation record. 

The code for an application is illustrated by this example: 

X 

A + Y =-> Y 

ADD 

The X and Y on the right represent the code corresponding to the A and Y on the left. Thus we gen- 
erate code that executes X and Y in order and leaves their values on the stack, where they can be 
popped by ADD. 

4.2 Conditional Expression 

Code for a conditional first evaluates the condition, leaving a Boolean value on the stack. A JMl r r 
instruction can then be used to test this value, skipping the alternate and jumping to the consequent 
when the value is true. 

(if B 
then T 
else F ) 

Of course the code for the alternate must end with a JMP to skip the consequent. 



B 

JMPT t 
F 

JMP uj 
LBL r 
T 

LBL uj 
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4 .3 Blocks 



The first step in the code for a block is the evaluation of the bound value E in the surrounding con- 
text. Two macroinstructions, ENTER and EXIT, surround the block body B , and handle the entry and 
exit of the block context; 

E 

I let v = E ENTER 
B j => B 

EXIT 

The ENTER macroinstruction must create the block's activation record, incorporating the bound value, 
and link the activation record into the static chain. It is equivalent to the following operations: 

PUSH EP {SL} 

EP-SP {set EP} 

That is, we push the old value of the EP register (which is a pointer to the surrounding context) onto 
the stack, thus forming the static link of the new activation record. The value of the bound value E is 
already on the stack, where it will be accessible as the local value in the new activation record. 
Transferring the contents of the stack pointer (SP) to the environment pointer (EP) installs the new 
activation record as the active one. 



The EXIT macroinstruction must save the value computed by the block (which is on the top of the 
stack) while the block’s activation record is deleted. Its code expansion is straight-forward: 



POP Tl 


{block value 


POP EP 


{SL} 


POP - 


{local} 


PUSH Tl 


{block value 



4.4 Function Definition 

Consider a function definition such as the following: 
' func / n = B 

x] 
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This is very much like a let block, except that execution of the function body B must be deferred until 
the function / is invoked: 



JMP uj 
LBL 4> 

B 

RETURN 
LBL u 
LDC <t> 
ENTER 
X 

EXIT 



{skip function body} 

{entry point} 

{body of function} 

{return to function} 

{here to skip function body} 
{stack entry point} 

{enter func. defn. block} 
{body of func. defn. block} 
{exit func. defn. block} 



The function body is represented by the LBL <f> (which is its entry point), the code B. and the 
RETURN macroinstruction (which is discussed below). The JMP w skips the function body, thus 
deferring its execution. The LDC 0 stacks the entry point address as the local value of the function 
block, which is then ENTERed and EXITed in the usual way. 



4.5 RETURN Instruction 



The RETURN macroinstruction has the task of saving the function *s value (which is on the top of 
the stack), restoring the caller’s environment, deleting the function’s activation record, leaving the 
function’s value on the top of the stack, and resuming execution of the caller. The code to accomplish 
this is: 



POP Tl 


{return value} 


POPEP 


{caller’s EP} 


POP T2 


{caller’s IP} 


POP- 


{SL} 


POP- 


{param} 


PUSH Tl 


{return value } 


JMP T2 


{resume caller} 
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The first POP saves the function’s value in temporary register Tl. The second restores the callers 
environment from the dynamic link (EP/IP pair). The third saves the caller’s resumption address in 
temporary register T2. The next two POPs delete the function’s activation record. The PUSH instruc- 
tion puts the function’s value back on the top of the stack, and the indirect JMP through T2 transfers 
control back to the caller. 

4.6 Function Invocation 

The code sequence for the function applicatiqn ‘/ A”’ is as follows: 

X 

SKIP S 

f X — LOD 

SKIP 6-1 
CALL 

where S is static distance to /’ s environment of definition. The first SKIP moves to the activation 
record of the function block so that the LOD can access the entry address. The second SKIP, which 
goes one static link further, accesses the environment of definition of the function. The CALL 
macroinstruction completes the invocation process. 

The CALL macroinstruction has the task of constructing an activation record for the callee and 
transferring control to the callee. This is accomplished by the following code expansion: 



POP Tl 


{get env . of defn. } 


POP T2 


{get entry address} 


PUSH Tl 


{static link} 


PUSH p 


{caller s IP} 


PUSH EP 


{caller's EP} 


EP-SP-2 


{callee’s S L } 


JMP T2 


{enter function} 


LBL p 


{return location} 



On entry to the CALL macroinstruction the top of the stack is the environment of definition of the cal- 
lee, the second on the stack is the entry point address, and the third on the stack is the actual parame- 
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ter value: 



env. of defn. 
entry point 
actual 



The first two are saved in registers Tl and T2. The actual parameter is left on the stack to form the 
first component of the callee’s activation record. The next component is its static link (whose value 
was saved in register Tl). Then we save the caller's IP (the resumption address p) and EP (which was 
in the EP register); together they constitute the dynamic link back to the caller. Finally, EP^SP— 2 
installs the callee's activation record as the active one, and the indirect JMP through T2 transfers con- 
trol to the function. The LBL p of course defines the return point in the caller. (Exercise for the 
reader: Why 4 -2’ in 4 EP— SP— 2 ?) The completed activation record looks like this: 



4.7 Example 



ep 



IP 



SL 



par am. 



Consider the following simple program: 

let K = 4 
fune fac n = 

(if (n = 0) 
then 1 

else ( n x fac ( n - 1 ) ) ) 
fac K 

The following code will be generated: 
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LDC 4 


local value K “ 4 


ENTER 


enter ‘let K = ' 


JMP L3 


skip body of fac 


LBL L4 


entry point of fac 


SKIP 0 


access formal n 


LOD 


fetch value n 


LDC 0 


stack 0 


EQL 


compare, ( n = 0) 


JMPT LI 


if true, skip alternate 


SKIP 0 


access formal n 


LOD 


fetch value n (to multiply) 


SKIP 0 


access formal n 


LOD 


fetch value n (to subtract) 


LDC 1 


stack 1 


SUB 


compute actual par am (n — 1 


SKIP 1 


access defn of fac 


LOD 


fetch entry point address 


SKIP 2 


access fac ? s env. of defn. 


CALL 


call fac ( n - 1) 


MUL 


multiply n by result of fac 


JMP L2 


skip consequent of if 


LBL Ll 


alternate of if: 


LDC 1 


stack 1 


LBL L2 


end of if 


RETURN 


return from fac 


LBL L3 


here to skip over fac 


LDC L4 


stack entry point of fac 


ENTER 


enter ‘fimc fac = ’ block 
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SKIP 1 


access context of K 


LOD 


fetch value of K 


SKIP 0 


access context of fac 


LOD 


stack entry point of fac 


SKIP 1 


access env. of defn. of fac 


CALL 


call fac K 


EXIT 


exit firnc fac = ’ 


EXIT 


exit ‘let K = ’ 



Exercise for the reader: trace the execution of this program showing all stack states. 
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5. Code Generation 



5.1 Introduction 

The code generator is like Eval and Unparse, except that we change the domain on which the 
evaluation is done: 

U n parse ( £) => “(3+5)” 

Eval(£,C) 8 

CodeGen (E,C) =s> <LDC [3], LDC[5], ADD> 

Notice that the “value’’ computed by CodeGen is a list of target machine instructions. 

5.2 Code Generation Relations 

The relations required for code generation are exact analogs of the Eval and Value relations in the 
interpreter: 

• CodeGen ( 2?, C) 

request code generation for E in context C 

Degree (CodeGen, 2), Domain (expr, 1, CodeGen), Domain (Context, 2, CodeGen). 

. Code (£/. E, C) 

U is the code for E in C 

Function (Code, exprxContext, code-list). 

5.3 Constants 

The code for a constant is simply the appropriate LDC instruction, which we assume to be generated 
by the function Con: 

*CodeGen (E, C), Con (£), LitVal ( V , E) 

=-> Code (< Con[ V] > , E). 

Note that because the range of Code is defined to be a code list, it is necessary to return Con V as a 
one-element list. 
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5.4 Applications 



We need an additional relation, OpCode, which is a table giving the target machine opcode for each 
primitive operator. This relation corresponds to the Meaning relation of the interpreter and the Tem- 
plate relation of the un parser. 

. OpCode (F, N) 

• F is the opcode for N 

• Function (OpCode, string, operation). 

The analysis rule for applications must request the code generation of the two argument expressions: 

*CodeGen (F. C). Appl (F), Left ( A\ F), Right ( }\ E) 

=> CodeGen (X, C), CodeGen ( Y, C). 

The synthesis rule catenates the code sequence for the arguments with the appropriate arithmetic opera- 
tion found in OpCode: 

Appl (F), Op ( A r , F), Left (A, E) , Right ( Y, F), 

"Code ( U, A, C), "Code ( V, Y, C), OpCode (F, N) 

=> Code ( U “ V ~< F> , E. C). 

Note that the opcode is made into a one element list so that it can be catenated with the code lists F 
and V. 

5.5 Conditionals 

The analysis rule for conditionals requests the code generation of the three parts of the conditional: 

"CodeGen ( F, C), ConEx (F), Cond (F, F), Conseq ( 7, F), Alt ( F, F) 

=$> CodeGen (F, C), CodeGen (7, C), CodeGen (F, C). 

The synthesis rule assembles these with the appropriate jump instructions: 
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ConEx (£), Cond ( B , E ), Conseq ( T , £), Alt (F, E ) 

*Code ( U , B, C), *Code ( V, T, C), "Code (IV, F, C), "Avail (r, u/) 



=?> Code ( 

U A 

< JMPT [t\> * 

W * 

< JMP [w], LBL [r ] > A 
V ~ 

< LBL H> , E, C). 

The only complication is that unique lables r ajid u; must be generated. 

5.6 Block Structure 

Contexts will be computed during code generation just as they are during evaluation. However, a 
name is bound to its static nesting level instead of its value (which is not known until runtime). 

Variable lookup is requested by the Access relation: its static nesting level is returned in the Loca- 
tion relation. 

• Access (A r , D, E , C) 
access A in D for E in C 

Function (Access, expr x Context, stringxContext). 

• Location (L, E. C ) 

L is the location for E in C 

Function (Location, exprx Con text, integer). 

The rules governing the Access process are exact analogs of the Lookup rules in the interpreter: 



i *> 

-lo- 



^Access (AG A, A, C), Binds (A, N, L), 

=> Location ( L , E , C) 

else ^Access (A^, D , A, C), Nonlocal ( A ' A) 

=> Access (AT, D ' A, C) 

else ^Access (A T , A, A, C) 

=> Break ("Undefined: ” *AT, E, C). 

5.7 Variables 

The analysis rule for variables simply request that Access determine the variable’s location: 

*CodeGen (A, C ), Var (A), Ident (A r . E) 

=> Access (A r , C\ E , C). 

The synthesis rule waits for the static distance to be returned in Location, and incorporates it into the 
appropriate SKIP instruction: 

Var (A), ^Location (L, E , C), Binds (C, — , A"), -’Rator (A, — ) 

=-> Code (< SKIP iff -L], LOD> , A, C). 

The condition ‘^Rator (A, )' is a bit of a kluge: it prevent the activation of this rule on variables that 

happen to be the operator of a function application, which must be handled differently. A runtime 
structure that supported function-valued functions (and variables) would eliminate the need for this 
kluge: exercise for the reader. 

5.8 Blocks 

The analysis rule for blocks requests code generation for the bound value and the block’s body. 

*CodeGen (A, C), Block (A), BndVar (AT, A), BndVal (A, A), Body (A, A), 

Binds (C, - , ff), *A vail (D) 

=> Context (A), Binds (D . N, K + 1), Nonlocal ( C , A), CodeGen (A, C), CodeGen (A. A). 

The bound value’s code is generated at the same static nesting level as the block (A'); the body is gen- 
erated at a level one greater (A"-bl). The synthesis rule merely catenates the code sequences with the 
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ENTER and EXIT instructions: 



Block (E), BndVal (AT, E), Body ( B , E), *Code ( E, A', C), *Code ( V, E, E), Nonlocal ( C, D) 
Code ( U * < ENTER> ~ V " < EXIT> , E, C) . 

5.9 Function Definition 

Code is generated for a function definition in very much the same way as for a block. The analysis 
rule requests code generation for the body of the function and the body of the function block, but this 
requires the creation of two new contexts: 

*CodeGen (E, C). FunDef (E), FunName (E, E), FunFormal (N, E), 

FunBody (E, E). FunScope (A'. E), Binds ( C, — , A"), *Avail (D. A) 

=> Context (E), Nonlocal ( C, E), Binds (E, E, AVl> ), CodeGen (A", E), 

Context ( A ), Nonlocal (E, A ), Binds (A, A r , K +2), CodeGen (E, A) 

The context E represents the context of the function definition block, which binds E to static nesting 
level AVI ( i.e . , one more than that of the surrounding context). Code for the body A" of the function 
definition block is generated in this context E. The context A represents the context of the function's 
body, which binds the formal A to its static nesting level (A'+2, i.e., one more than E's). A is the 
context in which code is generated for the function's body; notice that the nonlocal environment of A 
includes E, thus permitting recursive function invocations. 

The synthesis rule gathers the code generated for the function and block bodies, and assembles it 
into the complete code sequence: 

FunDef (E). FunBody (E, E), FunScope (A\ E), Nonlocal ( (7, E), 

*Code (£/, E, A), *Code ( U, X, E), *Avail (w, <t>) 

=> Code ( 

< JMP [w], LBL | <t>}> * U ~ 

< RETURN, LBL [«], 

LDC \<t> j, ENTER> ~ V ~ 

< EXIT> , E, C). 
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The label <p is the function’s entry point (which is left on the stack); the label u> is for skipping over the 
function’s body, so it will not be executed until it is called. 

6. Function Invocation 

For function invocations the analysis rule requests code generation for the actual parameter, and 
lookup for the function’s name: 

*CodeGen (E, C), Call (£), Rator [F, E), Rand (A, E), Var ( F), Ident ( N , F) 

=s> Access (A', C , F, C), CodeGen (A", C). 

Note that the code generator requires the Rator to be a variable, and also interprets that variable as the 
function s name (as opposed to a variable pointing to the function, etc.). 

The synthesis rules picks up from Location the static nesting level at which the function was 
defined, and uses it to assemble the code sequence: 

Call ( E) , Rator (F, E), Rand ( A\ E), "Location (L , F, C), "Code ( l\ A r , C), Binds (C,-, A') 
Code ( V ~ < SKIP \K-L ), LOD, SKIP K-L+ lj, CALL> . E, C). 

The first SKIP accesses the context in which the function was defined, since the local value of this con- 
text is the entry point address of the function; see 5.9 Function Definition above. The LOD moves the 
entry point address to the top of the stack. The second SKIP goes one further than the previous, which 
accesses the environment of definition of the function. The actual parameter, entry point address and 
environment of definition are left on the stack for the CALL macroinstruction (see 4.6, Function Invo- 
cation) . 
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APPENDIX A: Prototype Programming Environment 



The following is a loadable input file for the code generator described in this report. Its operation 
requires the PI-4 system listed in Part IV [ MacLennan86bj , which is not reproduced here. The com- 
plete system is accepted by the McArthur interpreter j McArthur84] , which differs in a few details from 
the H notation used in this report (see [MacLennan84] ) . A transcript of a test execution of this 
environment is shown in Appendix B. 



! CODE GENERATOR 
! 



! Reducing Append Function 



fn ap LL I : 
if LL= Nil -> [ 

else append first LL,, ap rest LL ]]; 



! Relations 



ne wrelation 
ne wrelation 
ne wrelation 
ne wrelation 
ne w relation 
ne w relation 
ne wrelation 
ne w relation 
ne wrelation 



{"CodeCen"}; 

{'Code”}; 

{"Access"}; 

{ rT Location"}; 

{"OpCode"}; 

{Create ConEx Code"}; 
{"CreateBlockCode"}; 
{"Cre ateFunDefCode"}; 
{"Create Fun Def2Code"}; 
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newrelation {"newlab"}; 
newrelation {"LastLabel"}. 



! Machine Op Codes 

! Alias procedure to define niladic opcodes: 
newrelation {"alias"}. 

act {< < if *alias (A, s) -> define {root, s, s}, A (s); > > }. 

alias {"LOD"}; 
alias {'ENTER"}: 
alias {'EXIT"}; 
alias {"CALL"}; 
alias {"RETURN"}; 
alias {'BREAK"}; 

! Monadic opcodes: 

fn LDC Ik 1 : "LDC " + k: 

fn JMP [1 : "JMP " - 1 

fn JMPT |1|: "JMPT " + 1: 

fn LBL |1 : "LBL "+ 1: 

fn SKIP [delta : 'SKIP " -r int_str delta; 

fn PUSH r : "PUSH " - r; 

fn POP ir : "POP " + r; 

! Opcodes used in operator applications: 

OpCode ("ADD", "+ "), 

OpCode ('SUB", 

OpCode ("MUL", "x"), 
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OpCode ("DIV", 
OpCode ("EQL", "= "). 
OpCode ("GTR", "> "). 



! CODE GENERATOR RULES 



define {root, ’GodeGenRules" < < 

! Incomplete Programs 

if *CodeGen (E, C), Undef (E) 

-> Code (\ BREAK], E, C); 

! Constants 

if *CodeGen ( E. C), Con (E), Litval (V, E) 

-> Code ( LDC int_str jVjjj, E, C); 

! Applications: Analysis 

if *CodeG en (E. C), Appl (E), Left (X, E) , Right (Y, E) 

-> CodeGen (X, C), CodeGen (Y, C); 

! Applications: Synthesis 

if Appl (E), Op (N, E), Left (X, E), Right (Y, E), *Code (U, X, C). "Code (Y, Y. C), OpCode (F, N) 
-> Code (ap [;U, V, fFjjj, E, C); 

1 Conditionals: Analysis 

if "CodeGen ( E. C) . ConEx (E). Cond (B. E) . Conseq (T. E) , Alt (F, E) 

-> CodeGen ( B, C) . CodeGen (T, C), CodeGen (F, C); 

! Conditionals: Synthesis 

if ConEx (E), Cond (B, E), Conseq (T, E), Alt (F, E), 

"Code ( U, B, C), *Code (V, T, C), *Code (W, F, C) 

-> CreateConExCode (U, V, W, E, C, newlab {}, newlab {}) ; 
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if *CreateCon ExCode (U, V, W, E, C, tau, omega) 

-> Code (ap [[ 

U, 

[ JMPT [tau]), 

W, 

JMP Iomega], LBL [tau]], 

V, 

LBL omega] ] ] ] , E, C) ; 

! Name Lookup Rules 

if ^Access (N, D, E, C), Binds (D, N, L) 

-> Location (L. E, C) 

else if ^Access (N. D, E, C), Nonlocal (Dpnme, D) 

-> Access (N, Dprime, E, C) 

else if ^Access (N, D, E, C) 

-> Break ( Undefined: M N. E, C); 

! Variables: Analysis 

if *CodeG en (E, C), Var ( E) , Idcnt (N, E) 

-> Access (N, C, E, C);* 

! Variables: Synthesis 

if Var (E), ^Location (L, E, C) , Binds (C, - , K), ~Rator (E, - ) 

-> Code ( SKIP [K-L] , LOD], E, C); 

! Blocks: Analysis 

if *CodeGen (E, C), Block (E), BndVar (N, E) , BndVal (X, E), Body ( B, E) , Binds (C, - K) 



- 22 - 



- > Create Block Code (C, N, K, X, B, newobj {}) ; 



if "Create BlockCode (C, N, K, X, B, D) 

-> Context (D), Binds (D, N, K+ 1), Nonlocal ( C, D), CodeGen (X, C), CodeGen (B. D); 

! Blocks: Synthesis 

if Block (E), BndVal (X, E), Body (B, E) , *Code (U, X, C), *Code (V, B, D), Nonlocal (C, D) 

-> Code ( ap [ [ U , [ENTER,, V, [EXIT]]], E, C); 

! Function Definition: Analysis 

if "CodeGen (E, C) , FunDef (E), FunName (F, E), FunFormal [N, E) , FunBody ( B, E), FunScope (X. 
Binds (C, — , K) 

-> CreateFunDefCode (C, F, K, X, N, B, E, newobj {}, newobj {}. newlab {}) : 
if *Cre ate FunDef Code (C, F, K, X, N, B, E, A, D, phi) 

-> Context (D), Nonlocal (C, D), Binds (D, F, K+ 1), CodeGen (X, D), Context (A), Nonlocal (D, A). 
Binds (A, N, K-f 2), CodeGen ( B, A); 

! Function Definition: Synthesis 

if FunDef (E), FunBody ( B, E), FunScope (X, E), *Code (U, B, A), *Code (V, X, D), Nonlocal (C, D) 
-> CreateFunDef2Code (newlab {}, newlab {}, U, V, E, C); 

if *CreateFunDef2Code (omega, phi, U. V, E. C) 

-> Code ( ap [ [ 

[ JMP [omega], LBL [phi]], U, 

[RETURN, LBL [omega], 

LDC « phi] , ENTER], V, 

EXIT]]], E, C); 

! Function Invocation: Analysis 
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if *CodeGen (E, C), Call (E), Rator (F, E) , Rand (X, E), Var (F), Ident (N, F) 

-> Access (N, C, F, C), CodeGen (X, C); 

! Function Invocation: Synthesis 

if Call (E), Rator (F, E), Rand (X, E), ^Location (L, F, C), *Code (V, X, C), Binds (C, - , K) 
-> Code ( ap | [ V, [SKIP K-L], LOD, SKIP [K-L+ l), CALL]]], E, C); 

! New Label Generator 

if *newlab (A), *LastLabel (n) 

-> A ( "L" ~ int _str n ), LastLabel (n 1); 

>>}• 

act {CodeGenRules}. 
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! Code Generator Commands 



newrelation {"CodeGenPending"}. 
define {root, "CodeGenCo mRules", < < 

! codegen Command 

if *Command ("codegen"), CurrentNode (E), CurrentContext (C) 

-> CodeGen (E, C), CodeGenPending (E), CommandPending (E); 

if Code (V, E, C). *CodeGenPending (E), *Comm andPending (— ) 

-> displayn {’Code generation completed."}; 

! showcode Command 

if ^Command ("showcode"), CurrentNode (E), Code (V, E, C) 

-> displayn {V}; 

if ^Command ("showcode"), CurrentNode (E), "Code (V, E, C) 

-> displayn {"No code available"}: 

> > }. 

act {CodeGenComRules}. 

define {root, ’CodeGenTests ", < < 

if *Test (A, 10) -> { Script {[ 

"begin", "let", "K". 4, "next", 'Tunc", 'Tac", "n". 

"if", "= ", ’Var". "n", "next". 0, "out", "next", 1, "next", 

"x". 'Var", "n", "next", "call", ’Var", 'Tac", "next", 

’Var", "n", "next", 1, 'Voot". "in". "next", "in", "next", 

"call", 'Var", 'Tac", "next", 'Var", "K", "root", "codegen", 'Showcode" 

]}; 
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A ( 'Test done”) ; 

}; 

>>}• 

act {CodeGenTests}. 

LastLabel ( 0) ; 

if *CurrentContext (— ) -> CurrentContext (newobj {}) . 
if CurrentContext (C) -> Binds (C, 0). 

displavn { ,f PI-5 System Loaded."}. 
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APPENDIX B: Transcript of f2 Session 



The following is a transcript of an Q session illustrating the operation of the prototype programming 
environment shown in Appendix A. The assertion ‘Script {testscript}’ causes the commands in 
testscript to be executed in order. The nth testscript is executed by ‘Test{n}\ Each command is 
printed on a separate line, followed by whatever output is generated by the programming environment. 
This transcript was produced by the McArthur interpreter McArthur84,. 

% omega 

OMEGA-1 11/30/84 

Use Cntl-D or exit{} to quit. 

For help, enter help{ Tr ?"}. 

To report a bug, enter Bugs{}. 
newrelation rule activated. 

> do{"Pl4.rul"}. do{ rr Pl5.rul M }. 

PI-4 System loaded 

OK 

> PI- 5 System Loaded. 

OK 

> Test{l0}. 

... begin 

... K let 

< expr> 

... 4 # 

... next 

< expr> 

... fac n func 
... if 
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< expr> 



< expr> 

... n var 
... next 

< expr> 

... 0 # 

... out 

(n = 0) 

... next 

< expr> 

... i # 

... next 

< expr> 

... x 

< expr> 

... n var 
... next 

< expr> 

... call 

... fac var 
... next 

< expr> 

< expr> 

n var 
... next 

< expr> 
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... 1 # 



... root 

[let K = 4 

func fac n = 

(if (n = 0) 
then 1 

else (n x fac (n - 1) ) ) 

< expr> | 

... in 
4 

... next 

func fac n = 

(if (n = 0) 
then 1 

else (n x fac (n - 1) ) ) 

< expr> 

... in 

(if (n = 0) 
then 1 

else (n x fac (n - 1) ) ) 

... next 
< expr> 

... call 
... fac var 
... next 
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< expr> 



... K var 
... root 

let K = 4 



func fac n = 

(if (n = 0) 

then 1 

else (n x fac (n • 1)) ) 
fac K 

... codegen 

Code generation completed. 

... showcode 

LDC 4, ENTER. J\1P L3, LBL L4, SKIP 0, LOD, LDC 0, EQL, JMPT Ll, SKIP 0, LOD, 
SKIP 0, LOD, LDC 1, SUB, SKIP 1, LOD, SKIP 2, CALL, MUL, JMP L2, LBL Ll, LDC 1, 
LBL L2. RETURN, LBL L3, LDC L4, ENTER, SKIP I, LOD, SKIP 0. LOD, SKIP 1. CALL, 
EXIT. EXIT 
> exit{}. 

Goodbye. 
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